There is no reason to mention the requirement of the Contact within the
Early definition.  The early dialog is created by presence of To tag
within the non 100 provisional response.  The lack of Contact does not
preempt it being an early dialog; it instead implies rfc2543 compliance
instead of rfc3261 compliance.

As mentioned within the rfc3261 section 12.1.1 quote, rfc3261 requires
the Contact (even if rfc2543 did not).


> -----Original Message-----
> From: Rockson Li (zhengyli) [mailto:zhengyli@cisco.com] 
> Sent: Tuesday, September 11, 2007 4:38 AM
> To: Miki HASEBE
> Cc: Paul Kyzivat (pkyzivat); sipping@ietf.org
> Subject: [Sipping] RE: another two questions 
> ondraft-ietf-sipping-race-examples-04
> 
> Mike,
> 
> Thanks for your quick reply.
> 
> The point I want some clarification is
> 
> In the draft Page 9
> 
> Early (Ear):  The early dialog is established by sending or receiving
>       a provisional response with To tag.
> 
> Here looks like as long as UA send or receive a  provisional 
> response with to tag , the early dialog is established.
> Actually as you said, "as described in section 12.1.1, UAS 
> MUST add a Contact header to the response if it constructs a dialog."
> So if UA sends/receives a provisional response with to tag , 
> but without Contact header , which I think is valid, it 
> should be stay in Preparative state.
> 
> So I just would like this draft add a few words here to make 
> it clearer:
> 
> Early (Ear):  The early dialog is established by sending or receiving
>       a provisional response with To tag and Contact header.
> 
> What do you think?
> 
> Thanks
> 
> Regards,
> -Rockson
> 
> -----Original Message-----
> From: Miki HASEBE [mailto:hasebe.miki@east.ntt.co.jp]
> Sent: Tuesday, September 11, 2007 4:26 PM
> To: Rockson Li (zhengyli)
> Cc: sipping@ietf.org; Paul Kyzivat (pkyzivat); 
> suzuki.yasushi@east.ntt.co.jp; tomoyuki.yoshikawa@east.ntt.co.jp;
> j.koshiko@east.ntt.co.jp
> Subject: Re: another two questions on
> draft-ietf-sipping-race-examples-04
> 
> Hi,
> 
> The answer is inline.
> 
> "Rockson Li (zhengyli)" <zhengyli@cisco.com> wrote:
> 
> > Hi Miki,
> > 
> > Thanks for your reply.
> > 
> > So for question 1 on "mortal early dialog", I think it 
> probably means 
> > the early dialog would be terminated locally, without 
> sending of any 
> > message explicitly, does it?
> 
> Yes, it does.
> 
> > For question 2 on 1xx resp establishing early dialog, Yes, as you 
> > said, "in page 162 of RFC3261, a Contact header of 1xx is "o"", but 
> > how does it prove it only applies to 100, Since from the table, it 
> > clearly shows any 1xx resp can take contact header optionally.
> > 
> > I think there're two categories of 1xx response, which intends to 
> > create early dialog and which not.
> > For those who intends to create early dialog as said in RFC3261
> > "12.1.1 UAS behavior", must have Contact header.
> > Since as you said, it's not clearly described in section 12.1.1, I 
> > wonder if you can make it clearer in this draft?
> 
> As described in section 8.2.6.2 of RFC3261, UAS MUST add a To 
> tag to the response other than 100.
> Furthermore, as described in section 12.1.1, UAS MUST add a 
> Contact header to the response if it constructs a dialog.
>  (A 1xx without To tag is taken into consideration only for backwards
>   compatibility with RFC2543. See section 12.1.2.) I guess 
> that means it is not so much "there're two categories of 1xx 
> response" as "there're 100 and 1xx other than 100 (101-199)".
> 
> I would like to know which description you think should be clarified.
> Do you mean that Contact header in page 162 of RFC3261 should 
> be essentially divided into 100 and 101-199?
> If it is correct, it is a minor improvement on the 
> description of RFC3261, but I think that it's outside scope 
> of this draft since it is not concerned with the sequence in 
> race condition.
> Do I understand your point correctly?
> 
> Thank you,
> Miki
> 
> > Thanks
> > 
> > Regards,
> > -Rockson
> > 


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP